The present application generally relates to information management systems, and more specifically to modular authoring and visualization of rules using trees.
Decisions made by business enterprises can be represented by one or more business rules. As used herein the term “rule” refers to one or more actions or operations that are performed upon the satisfaction of one or more conditions. A “business rule” refers to one or more business actions or business operations that are performed upon the satisfaction of one or more conditions. For example, in the context of a financial company that issues credit cards, the process for determining whether to offer a credit card to a particular individual based upon particular financial or demographic information can be represented by one or more business rules.
Formulating business decisions into business rules allow those business decisions to be automated using computer software. That is, the business logic and conditions defined by business rules can be embodied in computer software. Referring to the prior example, it is not uncommon for financial companies to automate, using computer software, the decision about whether a credit card should be offered to a particular individual. Conventionally, these types of computer systems use complex customized software to implement business rules.
A significant problem with using custom software to implement business rules is that the people in business organizations who decide on changes to business rules generally cannot themselves implement those changes in the computer software. When business logic or conditions change, the computer software must be updated to reflect the change. For example, in the context of issuing credit cards, if the minimum salary requirement is changed from X to Y, then the software must be manually updated to reflect the change in the minimum salary requirement from X to Y. Updating computer software generally requires technical expertise that the business people who decide the business rules may not have. These people are often financial analysts or high-level managers. Updating the software typically involves changing values in source code or data files and then “rebuilding” the software, which requires recompiling source code to generate object code and then linking the object code with libraries of other object code to generate a new runtime executable.
Rule engines have become critical in today's businesses. Some of the major reasons for this need are identified as: 1. the businesses' need to react quickly to a rapidly changing environment; 2. the growing prevalence of less technical users who are becoming responsible for building, editing and validating rules of the business (the business user); 3. an increased demand for businesses to create audit trails; 4. a “patch” for legacy systems; and 5. interest in business process management and integration with service oriented architectures.
Existing systems remain focused on the highly technical user and as such are not easy to use for business users. The existing solutions also force a top-down methodology whereby the user must understand the entire intent of a rule before being able to manipulate it. These solutions employ methods such as tables or spreadsheet type inputs and/or large decision trees. While such methods may be very effective for solving simple systems of rules, they become untenable for medium and large systems of rules. A trend in the known solutions is to use iconic representation, visual systems and natural language to represent rules in the system. Such methods promise increased ability to handle medium and larger systems of rules, yet they do so with the user as the primary composer of the formalized rule.
Users want to make business policy maintenance an activity of business users rather than developers. In industries like banking, insurance, marketing or travel, business users should be able to author and manage their business knowledge directly, without involving the IT (information technology) departments. However, business users may encounter difficulty in formalizing those rules in Boolean logic, that is, writing rules using expressions that involve the operators such as AND, OR and NOT.